I'd rather not land workarounds for non-critical engine-specific bugs.

This is an annoying lack of functionality in WebKit that should be fixed upstream, IMHO. Until then v8.dev works fine without.

I respectfully disagree. It looks super ugly on an iOS/iPadOS home screen and someone went the extra mile to open an issue about it. You (the V8 team) should weigh in on the WebKit bug and ask for it to be fixed. We all agree it's a temporary solution and not our problem, but in this case users should not have to suffer from it.

CC: @samthor.

I don't actually have a strong opinion here. PWACompat does its job but it might not be right here.

Users first.

@tomayac Is this still an issue on Apple devices? If it is, I'd agree that UX is most important and given that this adds overhead only for a specific User-Agent, it should be fine to include.

@tomayac Is this still an issue on Apple devices? If it is, I'd agree that UX is most important and given that this adds overhead only for a specific User-Agent, it should be fine to include.

This is still an issue. I have just made the conditional loading even lazier, so that it doesn't load on installed experiences.

Looking at what it does, do I understand right that we're interested in just <link rel="icon" ...> addition with a different size? If so, maybe it's easier to add the required size to the static markup?

The library dynamically (but lazily) creates splash screens(!) and icons for all devices.

Right, but my question is whether we need all of that to address the specific issue?

Right, but my question is whether we need all of that to address the specific issue?

We give people the same experience they get on Android when they install a PWA. Needed? Probably no. Nice to have? Probably yes.

Right, let me rephrase: are these other features also not working in iOS natively without PWACompat?

Right, let me rephrase: are these other features also not working in iOS natively without PWACompat?

This is the list of things the library does. The splash screens are a nice touch. Right now minimal-ui isn't supported on iOS, so it runs in a regular browser window (which doesn't trigger splash screens to show).

Sounds reasonable; one more question: it seems like the meta tag for the splash screen should always be present in the app to work, no?

If so, we probably should revert the last change so that PWACompat is included even for installed experiences.

Sounds reasonable; one more question: it seems like the meta tag for the splash screen should always be present in the app to work, no?

The splash screens will be dynamically created based on the Web App Manifest values. No meta tag needed.

If so, we probably should revert the last change so that PWACompat is included even for installed experiences.

When navigator.standalone evaluates to true, the library does nothing. Since right now this is false since we run in a browser tab, the library will be included. If we ever decide to run standalone (which iOS supports), we don't have to think of changing the code.

So you're saying that this latest added condition is not actually ever triggered? I'd suggest to just remove it for now then. If / when we decide to run in standalone, we can revisit the code (and see if Apple fixed their side by then).

So you're saying that this latest added condition is not actually ever triggered? I'd suggest to just remove it for now then. If / when we decide to run in standalone, we can revisit the code (and see if Apple fixed their side by then).

Done.

@tomayac […] given that this adds overhead only for a specific User-Agent, it should be fine to include.

Unfortunately, it doesn’t just add overhead for Safari. Check the DevTools → Network tab in Chrome, for example.